Turnbull China Bikeride/Turnbull China Bikeride - Disc 2.iso/BARNET/ARMLINUX/MAIL/9701/000017_owner-linux-arm…r.rutgers.edu _Wed Jan 22 02:43:07 1997.msg

Internet Message Format | 1998-01-25 | 6KB

Return-Path: <[e-mail]>
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id CAA31625 for <[e-mail]>; Wed, 22 Jan 1997 02:43:06 GMT
Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <65670-19574>; Wed, 22 Jan 1997 04:42:02 +0200
Received: by vger.rutgers.edu id <213477-2093>; Tue, 21 Jan 1997 21:30:23 -0500
Date:     Wed, 22 Jan 1997 01:29:44 +0000 (GMT)
From: Philip Blundell <[e-mail]>
X-Sender: [e-mail]
To: rmk <[e-mail]>
cc: [e-mail]
Subject: Re: Arm Linux
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Status: RO

On Wed, 22 Jan 1997, rmk wrote:

> It should not very difficult - I have been redesigning the processor support
> in ARM Linux, and now have it done the correct way ;)

:)

> page tables (= Updatable on the ARM610).  The ARM610 port I believe is just
> another case of the above - the ARM610 and ARM710 I believe are very much
> alike.

They are.  As far as I can tell the only difference is the cache size, and
someone from NetBSD posted that there is some difference in abort handling
as well.  I've got both data sheets here, but I haven't trawled through
them with a fine-toothed comb to see if there are any other differences.

> I have sorted out the memory management level code, however, I have to upload
> a new set of patches (sometime) for Alan to look into).

Right.  Well, no great rush.

> > 3. Tools and stuff.
> >     - ELF.  Linux is moving to ELF, and we don't want to be left
> >       behind.  ELF is important for shared libraries, especially...
>
> I'd prefer to hold off on this until a standard appears.  The reason is that
> it requires registration, and there are some complex issues that have to be
> addressed.  I do have some tools that will read ELF arm in a very minor way,
> but it would be totally incorrect to create our own standard until one appears
> from ARM Ltd.

I think we should work with ARM Ltd to produce a standard, if need be.
IMHO, ELF is important.  There is no point investing effort in dead
technology.

> The reason for this is that if we implement our own, and a standard does
> appear, then there will be major incompatabilities in the library and
> object files.

Yes, but if we run with a.out now, then all library and object files will
be utterly useless when ELF does appear.

> >     - glibc, or libc.so.6, is the new Linux shared library.  It needs
> >       to be ported to the ARM.
>
> This can be done after we have ELF support (since the latest libc versions are
> ELF only).

I know.  OTOH, preliminary work can be started before we have ELF.  For
example, ARM-code versions of many functions must be written - anybody who
enjoys writing optimised assembler is welcome to pitch in to this effort.

It is important that we have a stable C library.  If we are still running
from a ported libc 4, that is not good enough - even if you've been
amazingly dilligent, the chances are that it still contains bugs, and that
performance is going to be less than that of glibc.  It also lacks many
features, like threads, and introduces a compatibility nightmare (right
now, I'm going through the pain of making code compile for glibc -- I
don't want to have to do this in reverse for the ARM at a later date).

> Also, the 2.1.x kernels come into this category.  The 2.1.x kernels have an
> altered memory management checking system (it no longer verifies addresses
> before using them [will this cause problems on old hardware?]

I was thinking about this the other week.  I believe we should be OK.  Can
you provide any examples of scenarios that will go wrong?

> instead they build up tables of possible faulting instructions.  This
> will be extremely difficult for the ARM - we have an unrolled user
> memcpy routines in the kernel == loads of different addresses for
> faulting instructions, and the problem of how to generate the tables
> without ELF).

I believe the first of these has already been addressed (by davem, I
think) - you can give a _range_ of faulting instructions.  I think this
should cover virtually every case, since exceptions only tend to turn up
in constructs like:

if (copy_from_user(...)) return -EINVAL;

where the only instructions that can fault are the user-space accesses,
and any one of them faulting means the same thing.  If there are any more
complex uses of exceptions we may have to think more carefully, but I
don't think there is any fundamental problem.

The second is more of an issue, and is yet another reason why I believe we
should go for ELF.

> So which great person decided to go all out for ELF?  Is he mad?

He was probably just fed up with building a.out shared libraries.  In
the real world you _cannot_ insist that everybody pick a unique base
address for their library.  It totally stifles development.

> ELF will cause fundamental problems on the ARM3 machines - ELF appears to
> require a physical page to be mapped in twice, which is absolutely impossible
> on the ARM3 and older.

That's bad.  I shall have to have a think about that one.

> > 4. Weird stuff.
> >     - Some sort of emulator to allow RISC OS binaries to run might be
> >       a fun thing to have.
>
> I think that this may be more of a disadvantage than an advantage.  There
> will obviously be several SWI's that just cannot be implemented - OS_EnterOS,
> OS_Memory, OS_SetMemMapEntries, OS_IntOff etc.  I believe that basic may
> require at least OS_EnterOS, but that may be wrong.

Yes, obviously.  I wasn't suggesting we implement the whole of RISC OS,
but I believe something that can run simple applications would be doable,
entertaining and potentially useful.  I can't see how it could be a
disadvantage.

phil